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The  issue  of  control  structures  has  had  a heated  history  in  pro- 
gramming. To  put  this  issue  on  a solid  footing,  this  paper  reviews 
numerous  theoretical  results  on  control  structures  and  explores  their 
practical  implications. 

The  classic  result  of  Bohm  and  Jacopini  on  the  theoretical 
completeness  of  if-then-else  and  while-do  is  discussed.  Several  recent 
ideas  on  control  structures  are  then  explored.  These  include  a review 
of  various  other  control  structures,  results  on  time/space  limitations, 
and  theorems  relating  the  relative  power  of  control  structures  under 
several  notions  of  equivalence. 

In  conclusion,  a case  is  .nade  against  the  recent  arguments  of 
Knuth  [K2]  on  the  utility  of  the  GOTO  statement. 
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I.  INTRODUCTION 

In  the  last  decade  we  have  seen  the  rapidly  growing  Interest  In  the 
areas  of  structured  progranunlng  and  software  quality.  Although  the  major 
attention  has  been  placed  on  top-down  programming  techniques  and  control 
structures,  the  concern  over  the  quality  of  software  has  also  Included  the 
definition,  modularity,  clarity,  changeability,  and  documentation  of  programs. 

This  paper  focuses  on  the  Issue  of  control  strucures.  While  It  may  well 
be  argued  that  the  control  structure  Issue  has  been  entirely  overworked,  the 
debates  and  polarized  opinions  remain.  At  one  extreme  we  have  the  views  of 
Mills  [Ml],  who  has  religiously  advocated  the  use  of  the  If-then-else  and 
whlle-do  control  structures.  At  the  other  extreme,  we  have  the  views  of 
Knuth  [K2],  who  has  recently  given  vigorous  arguments  on  the  utility  of  the 

Over  the  years,  a number  of  theoretical  results  have  been  presented 
on  the  limitations  of  various  control  structures.  Notable  are  the 
works  of  Bohm  and  Jacoplnl  [Bl,  Ml],  Knuth  and  Floyd  [K3],  Bruno  and 
Stelglltz  [B2],  Peterson,  Kasaml  and  Tokura  [PI],  and  Importantly,  Kosarju 
[K4].  These  results  have  placed  the  control  structure  Issue  on  a firm 
foundation.  In  this  paper  1 present  a framework  for  reviewing  these  results 
and  discuss  their  practical  Implications. 

The  programming  language  PASCAL  Is  used  here  as  conmunlcation  language. 
Unfortunately,  PASCAL  omits  several  constructs  that  I consider  Important  In 
contemporary  languages.  To  remedy  this  situation,  1 have  made  a number  of  extensions, 

1 believe  that  these  extensions  will  pose  little 


as  required  by  the  examples, 
problem  for  the  reader. 


I 


II.  CLASSES  OF  CONTROL  STRUCTURES 


L. 


This  section  presents  various  classes  of  control  structures.  Aside 
from  minor  variants,  these  classes  embrace  the  control  structures  found  in  ^ 

most  algorithmic  languages.  Readers  who  are  familiar  with  these  control 
structures  may  need  only  a quick  reading  of  this  section  to  become  familiar 
with  the  terminology  given  here. 

(a)  D-structures . We  begin  with  the  definition  of  "D-structures", 

D for  Dljkstra,  as  in  [B2].  A D-structure  (see  Figure  1)  is  any 

program  constructed  only  from  the  following  1-ln,  1-out  primitive  structures 

(1)  basic  actions  (e.g. , assignment  statements,  procedure 
calls.  Input/output  statements), 

(il)  compositions  "sj^;s2"  of  two  D-structures, 

(lil)  conditional  constructs  of  the  form  p then  s^  else  S2" 
based  on  a predicate  p (having  no  side  effects)  and  two 
D-structures  s^^  and  S2»  and 

(iv)  loops  of  the  form  "while  p ^ s",  where  p is  a predicate 
(having  no  side-effects)  and  s is  a D-structure. 

D-structures  also  Include  conventional  for  loop  structures.  These  can  be 

readily  defined  via  basic  actions  and  while-do  loops. 

D-structures  have  received  prominent  attention  in  the  literature.  Bruno 

and  Stelglltz  [B2],  Ashcroft  and  Manna  [Al],  and  Knuth  and  Floyd  [K3]  have 

explored  the  reduction  of  arbitrarily  structured  programs  into  D-structure 

foim.  Mills  [Ml]  and  Dljkstra  [D2]  have  explored  programming  with  these 

structures,  and  numerous  other  researchers  [FI ,H1 ,L1 ,W3]  have  considered 

these  structures  in  various  ways. 

(b)  D'-structures.  The  class  of  D-structures  gives  rise  to  several  natural 
extensions.  One  class  of  control  structures,  here  called  D'-structures, 

is  shown  in  Figure  2.  This  class  comprises  the  class  of  D-structures,  with 
the  addition  of  the  following  1-ln,  1-out  structures:  single  branching 

if  statements,  n-way  branching  case  statements,  and  repeat-until  loops. 
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Fip.ure  (2)  Definition  of  D’-structures 


Aside  from  the  goto.  D' -structures  comprise  the  set  of  PASCAL  control  structures. 

I next  turn  to  some  substantive  generalizations  of  the  previous  control 

I 

structures.  These  generalizations  stem  from  the  notions  of  procedure  return 

i 

statements,  loop  exits  arising  from  exceptional  conditions,  and  repeated  loop 

1 

Invocations  from  within  loops.  ^ 

(c)  BJ  -structures 
— n 

First  consider  a definition  of  BJ  -structures  (due  to  Bohm  and  Jacopini  [Bl]), 

n 

where  n ^ 1.  A BJ^-structure  is  composed  of  basic  actions,  compositions,  if-tlien- 

else  structures,  and  1-in,  1-out  control  structures  , where  k n.  An  , -structure 

K K 

(see  Figure  3)  contains  k successive  predicates  and  actions  with  k exits,  one  for 
each  of  the  k predicates.  An  ^ -structure  is  equivalent  to  the  following 


program  schema. 


do  if  pj^  exit; 


if  P2 


1/  exit, 

V 

cycle 


If  an  fij^-structure  is  viewed  as  a procedure,  the  exit  escapes  above  would  be 
analogous  to  PL/I-like  return  statements.  Note  that  is  a while-do  structure. 
BJ^-structures  are  similar  to  that  proposed  by  Zahn  [Zl]. 

(d)  RE  , REG  , DRE  , and  DREG  Structures. 


Next  consider  the  definition  of  RE  -structures .and  their  variants.  An  RE  - 

n n 

structure  is  composed  of  basic  actions,  compositions,  if-then-else  structures,  exit 
commands  of  the  form  exit (i) , where  i is  a positive  Integer  constant  such  that 
1 ^ 1 i n,  and  repeat-end  constructs  of  the  form 


repeat 


end 


where  the  are  other  RE^-structures  (see  Figure  4).  On  execution,  the 
commands  within  r repeat-end  block  are  to  be  repeated  indefinitely  until  an 


command  is  encountered.  The  execution  of  an  exit (1)  command  causes  termination  - 

of  1 enclosing  repeat-end  loops.  In  the  case  where  there  are  fewer  than  i ' 

enclosing  loops,  all  enclosing  loops  are  terminated.  RE  -structures  are  similar 

n 

to  D-structures,  except  that  loops  may  be  exited  at  arbitrary  points  within  the  loop, 

REjj-structures  have  been  developed  from  the  control  structures  used  in  BLISS [W4]. 

An  REC  -structure  (see  Figure  5)  is  similar  to  an  RE  -structure,  with  the 
n n 

inclusion  of  additional  commands  of  the  form  cycle(i) . The  execution  of  a ■» 

cycle (i)  command  is  similar  to  an  exit (i)  command,  except  that  the  i-th  enclosing 
repaat-end  loop  is  re-executed. 

A DRE  -structure  is  defined  as  a RE  -structure  with  the  possible  inclusion 
n n 

of  while-do  structures.  The  execution  of  an  exit(i)  command  causes  termination 
of  the  i-th  enclosing  repeat-end  loop,  ignoring  any  enclosing  whlle-do  loops. 

A DREC^-structure  is  defined  as  a DRE^-structure  with  the  addition  of  cycle(i)  command 

RE^-structures  and  their  variants  conform  to  conventional  programs  for  wliich 

transfers  of  control  are  restricted  to  the  ends  or  beginning  of  enclosing  control  loo 

(e)  P -Structures  and  L-Structures 
n — — 

Finally,  a P^-structure  is  defined  as  any  well-formed  structure  stich  that  all 
1-ln,  1-out  sub-structures  have  at  most  n predicates.  An  L-structure  is 
defined  as  any  well-formed  structure,  l.e.,  any  structure  with  no  restrictions  on 
the  number  or  configuration  of  predicates,  actions,  and  transfers  of  control.  An 
L-structure  corresponds  to  a program  with  free  use  of  labels  and  goto  statements. 

The  above  control  structures  embrace  most  of  the  explicit  control 
structures  found  in  conventional  languages.  It  is  important  to  note 
that  these  control  structures  do  not  take  into  account  various  "scope" 
rules  often  associated  with  these  control  structures.  In  PASCAL  for 
example,  the  value  of  a for- loop  control  variable  upon  exit  is 

undefined.  Such  issues  arising  from  the  value  of  Internal  variables  when  control 
is  transferred  into  or  out  of  a control  loop  are  not  treated  In  this  paper. 


. i 


- 8 - 


I 

« 


III.  THE  NOTIONS  OF  REDUCIBILITY  AND  EQUIVAT.F.NCE 

Numerous  results  on  the  relative  power  of  control 
structures  are  presented  in  the  next  section.  In  an  attempt  to  present 
these  results  in  a rigorous  but  conceptually  simple  framework,  we  first 
define  five  sets  of  conversion  rules  for  converting  a control  structure 
Into  another  form,  and  then  Introduce  the  notions  of  "reducabillty" 
and  "equivalence"  of  classes  of  control  structures  under  these  conversion 
rules.  These  notions  are  motivated  by  Kosaraju  [K4] . 


3.1  Conversion  rules 


In  defining  the  various  notions  of  conversion  of  a structure  to  a 
structure  S2,  the  following  five  properties  are  singled  out: 

(PI)  For  every  input  S2  computes  the  same  function 

as  . (i.e.,  S_  performs  the  same  computation 

as  SJ^.) 

(P2)  The  primitive  actions  and  predicates  in  S-  are 
precisely  those  of  S^. 

(P3)  For  every  input,  the  sequence  of  primitive  actions  and 
predicates  executed  in  $2  is  identical  to  that  in  S^. 

(P4)  S2  can  be  obtained  from  Sj^  by  "node  splitting".  (Basically, 
node  splitting  allows  one  to  eliminate  structures  with  mul- 
tiple inputs  by  making  multiple  copies  of  the  paths  through 
the  structures  [see  PI].) 

(P5)  Each  occurrence  of  a primitive  action  or  predicate  in 

is  used  at  most  once  in  $2.  (i.e.,  multiple  copies  of 

predicates  and  actions  in  are  not  allowed.) 


The  conversion  rules  can  now  be  easily  stated  as  follows: 

(a)  Very  Strong  Conversion.  A structure  is  said  to  be  "very  strongly" 
convertible  to  a structure  S2  iff  properties  (PI)  through  (P5)  are 
< satisfied. 

I 

j "Very  strong  conversion"  is  indeed  very  strong.  Basically,  the  only 

allowed  rewriting  rule  in  converting  to  $2  is  a reconfiguration  of  the 

i ^ 


existing  predicates  and  actions  In  From  a programmer's  viewpoint, 

there  Is  one  Important  consideration,  namely  that  and  S2  differ  only 
In  notatlonal  convenience. 

(b)  Node-Splitting  Conversion;  A structure  Is  said  to  be  "node- 
splitting" convertible  to  Iff  properties  (PI)  through  (P4)  are 
satisfied. 

Node-splitting  conversion  is  still  quite  strong.  Basically,  $2  must  be 
derivable  from  by  well-defined  rewriting  rules  (node-splitting). 

(c)  Strong  Conversion.  A structure  is  said  to  be  "strongly"  convertible 
to  a structure  S2  iff  properties  (PI)  through  (P3)  are  satisfied. 

Strong  conversion  is  clearly  not  as  strong  as  node-splitting  conversion 
for  a restructuring  of  the  primitive  actions  and  predicates  In  Sj^  Is 
allowed  In  S2.  Nevertheless,  the  reduction  Is  still  strong  In  the  sense 
that  the  computation  sequences  In  and  $2  must  still  be  identical. 

(d)  Semantic  Conversion.  A structure  Sj^  Is  said  to  be  "semantically" 
convertible  to  S2  iff  properties  (PI)  and  (P2)  hold. 

Semantic  conversion  Implies  a significantly  less  restrictive  condition 
than  the  above  notions  of  conversion, for  the  only  restriction  on  the 
conversion  of  S^  to  $2  is  the  prohibition  of  "new  semantics",  l.e., 
new  actions,  predicates,  or  variables. 

(e)  Computational  Conversion.  A structure  S^  is  said  to  be  "computationally" 
convertible  to  S2  Iff  property  (PI)  Is  satisfied. 

Computational  conversion  Is  Indeed  weak.  For  the  reduction  of  Sj^  to  S2 
we  only  require  that  the  two  structures  compute  the  same  function.  The 
Introduction  of  new  predicates,  actions,  or  variables  are  all  allowed. 

f 
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3. 2 The  Notions  of  Reduclblllty  and  Equivalence 

The  issue  of  "relative  power"  of  various  classes  of  control 
structures  can  now  be  precisely  stated.  Given  a set  of  conversion 
rules,  a class  of  structures  is  said  to  be 

(a)  reducible  to  a class  (notatlonally  < C2)  if  every  structure 
in  can  be  converted  to  a structure  in  C2,  but  not  necessarily 
vice  versa. 

(b)  strictly  reducible  to  a class  C2  (notatlonally  < C2)  if  every 
structure  in  can  be  converted  to  a structure  In  C2,  but  not 
vice  versa. 

(c)  equivalent  to  a class  C2  (notatlonally  ^ C2)  if  every  structure 
in  can  be  converted  to  a structure  in‘'’C2  and  vice  versa. 

Given  a set  of  conversion  rules  from  to  C2,  reduction  intuitively  implies 

that  is  "less  powerful"  than  C2,  strict  reduction  implies  that  is 

"strictly  less  powerful"  than  C2,  and  equivalence  implies  that  and  C2  are 

"equally  powerful." 

Given  the  notions  of: 

(a)  very  strong  conversion 

(b)  node  splitting  conversion 

(c)  strong  conversion 

(d)  semantic  conversion 

(e)  computational  conversion 

we  shall  denote  the  "reduction",  "strict  reduction",  or  "equivalence" 
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IV  RESULTS  ON  CONTROL  STRUCTURES 


^ This  section  reviews  several  major  results  on  control  structures 

and  discusses  their  practical  significance.  These  results  fall  Into 
two  main  categories: 

(1)  The  classic  result  of  Bohm  and  Jacoplnl  [Bl]  on  the  theoretical 
completeness  of  D-structures. 

(2)  The  results  of  Kosaraju  [K4],  which  place  all  of  the  control 
structures  given  earlier  Into  a hierarchy  under  semantic 
conversion. 

4.1  The  Bohm  and  Jacoplnl  Result  ' 

The  classic  result  of  Bohm  and  Jacoplnl  on  the  theoretical  completeness  of  D-structures 
was  perhaps  the  first  major  (albeit  initially  little  recognized)  result  in 
structured  programming.  This  result  Is  well-described  in  a paper  by  Mills  [Ml]. 

Briefly  stated,  the  Bohm  and  Jacoplnl  paper  [Bl]  makes  the  following  points! 

(a)  D r L,  i.e.,  any  L-structure  (Including  those  permitting  arbltraty 
transfer  of  control)  can  be  converted  to  a computationally  equivalent 
D-structure. 

(b)  In  the  computational  conversion  of  an  L-structure  to  a D-structure, 
boolean  control  variables  may  be  introduced,  but  the  values  may  be 
stored  in  a stack  and  only  the  value  of  the  top  element  in  the 
stack  need  be  known  at  any  given  point  in  the  program. 

The  Importance  of  result  (a)  was  the  establlshaent  that  the  "goto" 

statement  is,  at  least  theoretically,  not  needed  to  perform  computations,  and 

that  three  simple  but  familiar  control  structures:  sequential  composition,  If- 

then-else,  and  while-do,  are  in  fact  theoretically  complete  control  structures. 


i 


I 


T 


- 12  - 


1:  if  All] 

then 


else 


A[m]  :=  X 


< X 

^ L[i]  = 0 

then  L[i]  :=  m 

else  begin  L : = L[l] ; 

goto  1 

end 

^ R[i]  = 0 

then  R[i]  :=  m 

else  begin  i :=  R[i] 

goto  1 

end; 


Figure  (6a)  A control  structure  not  reducible  to  a D-structure 
without  new  variables  or  predicates 


V ;=  false; 


while  ~|v  do 

U A[l]  X 

then  if  L[i]  = 0 

then  begin  L[i] 

V : = 


end 

else  1 :»  L[i] 


:=  m; 
true 


else  ^ RIU  » 0 

begin  Rfl]  :=  m; 
V :=  true 

end 

else  i :=  R[i]; 


A[m]  X 

Use  of  a nev  variable  to  reduce  the  control  structure 
of  (6a)  to  a D-atructure 


Figure  (6b) 
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An  exampl«  of  the  conversion  of  an  L-structure  into  a D-structure  is  given 

in  Figure  (6) . This  example  comes  from  a tree  searching  and  insertion  program 

of  Knuth  [K2],  The  index  m denotes  the  array  location  into  which  a variable  x 

is  to  be  Inserted.  The  arrays  L and  R denote  the  left  and  right  branches  of  a 

tree  organization  that  is  superimposed  on  an  array  A.  Figure  (6a)  depicts  a 

program  that  contains  two  transfers  of  control  back  to  the  structure  entry  point. 

Figure  (6b)  shows  a computationally  equivalent  D-structure.  The  conversion 

employs  an  intermediate  boolean  variable  whose  value  is  checked  at  the  end  of 

a while-do  structure.  Two  comments  are  in  order  here.  First,  the  D-structure 

of  Figure  (6b)  is  not  necessarily  less  understandable  than  the  L-structure 

of  Figure  (6a).  Second,  as  we  shall  discuss  later,  the  L-structure  of  Figure 

(6a)  can  be  nicely  expressed  without  goto's  using  an  REC^-control  structure. 

semantically 

The  question  arises,  under  what  conditions  is  a control  structure/convertible 
to  a D-structure,  i.e.  without  introducing  new  boolean  variables  or  changing  the 
particular  semantics  of  a program.  The  answer  [K4]  lies  in  the  detection  of 
two  loops  with  two  or  more  distinct  exits.  In  general,  an  L-structure  is 
convertible  to  a D-structure  under  semantic  conversion  if  and  only  if  the 
structure  does  not  contain  a traceable  loop  with  two  distinct  exits.  If  a 
structure  contains  only  loops  with  one  exit,  the  structure  is 'convertible  to  a 
D-structure. 

For  example,  consider  the  program  schema  of  Figure  (7),  taken  from  a 
program  in  Gross  and  Bralnerd  [Gl].  This  is  a typical  structure  that  cannot  be 
converted  to  a D-structure  without  new  variables  or  actions.  Here  we  have  a 
loop  consisting  of  the  sequence  ®3PiP2®4^3®5  exits,  one  through  a^  and 

one  through  a^.  Note  that  the  branch  to  a^  is  not  an  exit  from  this  loop  since 
the  flow  of  control  must  return  to  a^.  Similar  arguments  hold  for  the  structure 
of  Figure  (6a). 
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4.2  Kosaraju's  Hierarchy  of  Control  Structures 

There  have  been  numerous  attempts  to  discover  the  limitations  of  D-structures 

as  well  as  to  explore  the  expressive  power  of  other  control  structures.  Knuth 

and  Floyd  [K3]  have  shown  that  D L and  given  some  intuitive  Ideas  that 

D L.  Bruno  and  Stelglltz  [B2]  have  formally  proved  that  D L.  Kosaraju  [K4] 

and  Peterson  et  al  [PI]  have  proven  that  D < L.  These  results  point  to  the 

sem 

fact  that  there  are  Indeed  fully  labeled  programs  that  cannot  be  converted  to 
D-structure  form  without  changing  the  length,  execution  time,  or  primitives 
of  a given  program.  Peterson  et  al  have  also  shown  similar  results  for  RE 

n 

structures,  i.e.  RE^  L,  and  RE„  =ns 

These  results  fail  to  answer  one  important  question,  namely  how  do  the 
structures  given  earlier  relate  to  each  other.  The  results  of  Koraraju  [K4] 
resolve  this  question. 

The  basic  results  of  Koraraju  are  outlined  in  Figure  (8).  [ref  [K4]  and 
private  communication] . An  upwards  solid  line  connecting  one  class  of  struc- 
tures to  another  class  Cj  means  that  is  strictly  reducible  to  C2  under 
the  notion  of  semantic  conversion,  i.e.,  Cj^  ^ sem  ^2"  upwards  dotted  line 
means  that  C,  ^ C..  The  main  results  defined  in  Figure  9 are  summarized  as 

follows.  Under  the  notion  of  semantic  conversion, 

(1)  for  m<n,  there  exist  BJ  -structures  which  cannot  be  converted  to  BJ  -struc- 
tures. In  particular,  without  the  introduction  of  new  predicates  or  actions, 
BJ2-8tructures  are"more  powerful"than  BJj^-structures,  which  are  identical  to 

D-struc tures. 


i 
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(2)  RE^^-structuras  are'«more  power  ful"than  BJ^-s  true  Cures  or  D-structuees. 

RE  -structures  are  equivalent  to  REC  -structures  (as 
yet,  this  is  an  unprovfen  conjecture).  Somewhat  8urprie!ngly.  it  is 
believed  the  addition  of  the  cycle (i)  command  does  not  add  theoretical 
power  to  the  repeat-exit  control  structure  under  semantic  conversion. 

-structures  are  moM  powerful  than  RE  -structures.  Again  somewhat 
urprislngly,  the  addition  of  a whlle-do  Sontrol  structure  does  in  fact 

add  theoretical  power  to  the  RE  -control  structure.  

n 

(5)  Finally,  if  no  a priori  bound  is  placed  on  the  index  n,  any  fully  labelled 
structure  is  semantically  convertible  to  an  REjj,  REC^^,  ot^REjj  structure 
Other  results  not  shown  in  Figure  (8)  are  given  in  [K4J. 

As  an  example  Illustrating  this  hierarchy,  consider  the  structure  of 
Figure  (9a),  which  is  based  on  the  control  structure  recently  proposed  by 
Zshn  [Zl,  K2].  This  control  structure  represents  a computation  where  a 
computation  sequence  is  to  be  repeated  until  one  of  a number  of  "events" 
occurs.  Upon  realization  of  one  of  the  events,  the  repeated  loop  is  exited. 
Termination  of  the  loop  then  invokes  a specific  computation  determined  by 
the  event  that  has  actually  occurred.  This  control  situation  is  a fairly 
natural  one,  and  is  quite  close  to  a BJ^-structure. 

Noting  that  D<ggnj  BJ^,  the  conversion  of  this  structure  to  a D-structure 
requires  a new  variable,  as  shown  by  the  program  in  Figure  (9b).  On  the  other, 
hand,  noting  that  BJjj<ggQ  REj^,  this  structure,  can  be  nicely  converted  to 

an  REj^-structure,  which  is  given  in  Figure  (9c). 

As  another  example  of  the  utility  of  REj^-structure,  consider  the  tree 
searching  and  insertion  of  the  program  of  Figure  6.  This  program  can  be 
readily  converted  to  an  RE^-structure,  as  shown  in  Figure  (lo). 

From  a programmer's  viewpoint,  the  results  given  above  suggest  that  there 
is  some  question  over  the  practical  utility  of  programming  with  only  D or 
D'-structures.  Aside  from  questions  of  efficiency,  the  examples  also  suggest 
that  the  use  of  stronger  control  structures  like  RE-structures  and  their  variants 
may  obviate  the  need  for  go  to ' s . In  the  next  section  I present  a key  example 
that,  in  fact,  presents  evidence  counter  to  these  suggestions. 


V false 
while  ■»  V do 


beglr 


:■  true; 


then 


begin  bj^; 

event  • “ 1 1 

end 

else  begin 

li  ^ 

then  begin  b2; 

event 

end 

else 


1, 


begin 

l!=P. 

then  begin  bj,; 

event 

end 

else  begin 

V ;■  false 
end 


end 


end  ; 


case  (event)  of 


n: 


end 


c 

n 


Figure  ( 9b)  Zahn's  Control  Structure  expressed  as  a D-structure  (under 
computational  converslonY  


case  (event)  of 
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V.  AN  EXAMPLE 

When  all  is  said  and  done,  the  practicing  programmer  is  primarily  interested 
in  solving  problems  using  some  given  set  of  control  structures.  Theorems  and  re- 
sults on  the  conversion  of  one  program  or  flowchart  into  another  form  may  be  of 

some  interest,  but  certainly  not  the  basic  issue.  This  section  presents  ^n  example 

directed  at  resolving  this  important  issue.  In  particular,  are  there  problems 

for  which  D or  D'-structures  do  not  provide  as  clear  a solution  as  REC  -structures 

n 

More  precisely,  are  there  problems  for  which  there  is  a solution  S2  e REC2 
and  for  any  reasonable  solution  Sj^  e D,  Si  =^5^  and  S2  is  significantly  clear 
than  Si? 

I must  admit,  the  problem  presented  here  was  originally  proposed  with  the  hope 
of  supporting  a positive  answer  to  the  above  question.  The  problem  appeared  to  have  the 
right  set  of  ingredients,  l.e.  the  need  for  cycling  back  to  a loon  entrv  from  with- 
in a loop  and  the  need  for  an  escape  exit  nested  vl thir  multiple  loops. 

This  problem  is  called  the  "qualified  name'  nroblem.  Basically,  the  problem 
is  to  write  a program  segment  to  set  the  value  of  a variable  LEGAL_NAME  to  true  or 
false  according  to  whether  a given  PL/I  qualified  name  is  a legal  or  Illegal  reference. 
In  PL/I,  one  can  declare  "structures"  with  nested  components,  e.g. 

DFCLARF  1 A DECLARE  1 X , 

? B 2 B , 

3’c:har(5),  3 c float, 

3 n FTXro  ; 3 E FLOAT  ; 

A "reference'  to  a structure  is  considered  legal  if  and  only  if  the  reference  re- 
fers to  one  and  only  one  declared  structure  component.  Using  the  above  declaratior s , 

A,  A.B,  A.B.C,  and  B.E  are  legal  references,  whereas  B and  B.C  are  Illegal. 

To  solve  this  problem,  a number  of  primitives  are  assumed: 

(a)  A linked  list  of  entries  call  QUALIFIED_NAME,  which  represents  the 
in'ormatlon  about  a qualified  name. 

(b)  A function  BASE_ENTRY,  which  when  applied  to  a qualified  name 

yields  the  base  entry  in  the  list.  e.g.  the  base  entry  in  the  qualified 
name  A.B.C  is  the  entry  for  C. 


**!"^**^ 


i;^P  III. 
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(c;  A linked  lint  of  entries  called  SYMBOL_TABLE , which  contains  entries 
for  each  identifier  declared  in  a program. 

(d)  A function  NEXT,  which  when  applied  to  a null  symbol  table  entry  gives 
the  first  entry,  and  which  when  applied  to  a non-null  symbol  table 
entry  gives  the  next  entry  in  the  symbol  table  (assuming  some  pre- 
determined order) . 

(e)  A function  FATHER,  which  when  applied  to  a qualified  name  entry  or  symbol 
taV>le  entry,  yields  the  next  higher-order  entry  in  the  corresponding 
qualified  name  or  symbol  table,  or  the  null  entry  if  there  is  no  father 
entry.  For  example,  in  the  linked  list  for  A.B.C,  the  father  of  the 
entry  for  C is  the  entry  for  B,  and  the  father  of  the  entry  for  A is 

the  null  entry. 

(f ) A function  NAME,  which  when  applied  to  a qualified  name  entry  or  a 
symbol  table  entry  yields  the  identifier  for  that  entry. 


A solution  to  this  problem  using  REC2-structures  is  given  in  Fjgure  (Ua).  Here, 
the  PASCAL  case  statement  is  extended  to  allow  for  multiple  case  conditions.  This 
solution  is  quite  clear  and  makes  liberal  use  of  cycles  and  exits.  The  conver- 
sion of  this  solution  to  a D or  D'-structure  under  restricted  conditions (a. e.  any 
of  the  properties  P2  through  P5)  is  highly  tedious  exercise,  resulting  in  a much 
longer  and  less  efficient  solution.  Nevertheless,  a new  (computationally  equiva- 
lent) solution  using  ij-structureB can  be  devised,  as  given  in  Figure  (111). 

This  solution  compares  quite  favorably  with  the  solution  using  REC2-8tructures . 

It  is  Important  to  comment  here  that,  in  addition  to  the  formal  results  presented 
earlier,  that  there  have  been  numerous  other  papers  IF1,L1,P1,W4,Z1]  suggesting  the 
limitations  of  D or  Distructures.  As  far  as  I can  perceive,  most  of  these  papers 
only  compare  the  conversion  of  abstracted  program  schemas  or  flowcharts  into  D or 
D'-structure  form.  Not  once  have  I seen  a problem  that  really  shows  the  limita- 


tions on  clarity  with  D or  D' -structures.  The  classic  case  of  the  abnormal  exit 
from  some  deeply  rested  procedure  just  does  not  hold  weight,  for  the  notion  of 


passing  control  to  a procedure  that  does  not  return  control  to  the  calling  pro-  1 

gram  segment  Is  counter  to  the  very  notion  of  1-ln,  1-out  control  structures. 

I have  long  supported  the  view  that  D and  D’ structures  are  not  sufficient 
for  the  practicing  programmer.  Recently  I have  tried  to  support  this  opinion  with 

a 

example  problems  far  too  numerous  to  mention  here.  Frankly,  I have  not  found  such 
an  example  problem. 
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QN_ENTRY 

BASE_ID 

ST_ENTRY 

DIRECTJilT 

mJM  PARTIAL  HITS 


- BASE_ENTRY(QUALIFIED_NAME). 

- NAME(QN_ENTRY); 

- NULL;  ~ 

“ false 

- 0; 


repeat 


STJENTRY  NEXT(ST_ENTRY) ; 

case  (ST_ENTRY-NULL,  NAME(ST_ENTRY)-BASE_ID)  of 
(T.F):  exit  (1) 

(F,F):  cycle  (1) 

(T,T):  {cannot  occur} 


(F,T):  begin 


L0CAL_QN_ENTRY 

L0CAL_ST_ENTRY 

SKIP 


- FATHER (QN_ENTRY); 

- FATHER(ST_ENTRY); 
■ false; 


repeat 


case  (LOCAL_QN_ENTRY-NULL,  LOCAL_ST_ENTRY-NULL)  of 
(T.T):  if  SKIP 

then  NUM_PARTIAL  HITS  NUMJ>ARTIAL_HITS  + 1 

else  begin  DIREcf_HIT  true; 

exit (2) 

end 

(T.F);  NUM_PARTIAL_HITS  NUM_PARTIAL_HITS  4 1 
(F.T):  {no  operation) 


(F.F):  begin 


~lf  NAME  (LOCAL_QN_ENTRY)-NAME(LOCAL_ST_ENTRY) 

then  LOCAL_QN_ENTRY  FATHER (LOCAL_QN_ENTRY) 
else  SKIP  :■  true; 

LOCAL_ST_ENTRY  ;»  FATHER (LOG AL_ST_ENTRY ) ; 
cycle  ( 1) 


end  {case); 
cycle(2) 
end  {repest} 


end  {case) 


if  DIRECT_HIT  V (NUM_PARTIAL_HITS-1) 
then  LEGAL  NAME  true 

else  legal" NAME  false 


Figure  (lla)  A Solution  to  the  Qualified  Name  Problem  as  an  REC^-Structure 
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QN_ENTRY 

BASE_ID 

ST_ENTRY 

DIRECT_HIT 

NUM  PARTIAL  HITS 


- BASE_ENTRY(QUALIFIED_NAME)  ; 
■=  NAME(QN_ENTRY); 

- NEXT (NULL) 

“ false; 

- 0; 


while  (ST_ENTRY  ^ NULL)  a ( DIRECT_HIT)  ^ 
begin 

i^  NAME  (ST_ENTRY)  - BASE_ID 
then  begin 


L0CAL_QN_ENTRY:-  FATHER  (QNJENTRY) ; 

LOCAL_ST_ENTRY;-  FATHER  (ST_ENTRY) ; 

SKIP  :=  false; 

while  (LOCAL_QN_ENTRY  ^ NULL)  a (L0CAL_ST_ENTRY  j*  NULL)  ^ 
begin 


if  NAME(L0CAL_QN_ENTRY) 
then  L0CAL_QN_ENTRY 
else  SKIP 
LOCAL  ST  ENTRY 


NAME (LOCAL_ST_ENTRY) 
FATHER  ( LOC  AL_ft'N_ENTRY  ) 
true; 

FATHER (LOCAL  ST  ENTRY); 


case  (LOCAL_QN_ENTRY  “ NULL,  LOCAL_ST_ENTRY  - NULL)  of 
(T,T):  ^ SKIP 

then  NUM_PARTIAL_HITS  :»  NUM_PART1AL_HITS  + 1 
else  DIRECT_HIT  true 

(T,F);  NUM_PARTIAL_HITS  NUM_PARTIAL_HITS  + 1 

(F,T):  {no  operation} 

(F,F):  (cannot  occur) 

end  {case} 

Mid  {begin}^ 


»r  ENTRY  NEXT  (ST  ENTRY), 


^ DIRECT_HIT  V (NUM_PARTIAL_HITS  -1) 
then  LEGAL_NAME  true 

else  LEGAL  NAME  false 


Figure  (lib)  A Solution  to  the  Qualified  Name  Problem  as  a D’-Structure 


I 

VI.  CONCLUSIONS 

There  are  three  basic  conclusions  of  this  paper. 

(1)  From  a programmer's  viewpoint,  results  relating  to  the  conversion  of 

^ one  program  form  to  another  form  under  restricted  conversion  rules 

are  mainly  of  theoretical  Interest  only. 

(2)  The  utility  of  the  goto,  as  well  as  other  higher  (non  D or  D')  control 
structures.  Is  seriously  (•uestlone^. 

(3)  The  utility  of  D and  D'-structures  Is  supported. 

My  first  conclusion  may  be  difficult  to  accept,  for  there  have  been 
numerous  formal  results  (presented  here  and  elsewhere)  on  the  limitations 
of  control  structures  under  various  notions  of  conversion.  It  Is 
tempting  to  conclude  from  th«sc  results  that  the  practicing  programmer 
would  be  unduly  limited  with  the  control  structures  that  did  not  hold  up 
well  under  conversion.  As  mentioned  earlier,  the  practicing  programmer  Is 
hardly  ever  concerned  with  converting  programs  from  one  form  Into  another. 

My  contention  Is  that  formal  results  on  conversion  provide  l#ttle  real  sup- 
port for  the  practical  use  of  any  particular  control  structure. 

My  second  conclusion  agrees  with  the  views  of  Mills  [Ml]  and  others. 

I have  found  no  evidence  for  retaining  the  goto  statement.  The  recent  work 
of  Knuth  [K2]  surveys  many  opinions  on  the  use  of  various  control  structures, 
Including  the  goto.  However,  I strongly  believe  the  argximents  that  he  advances 
In  favor  of  the  goto,  clarity  and  efficiency,  are  not  supported. 

The  argument  from  clarity  Is  exemplified  by  "Sometimes  it  Is  necessary 
to  exit  from  several  levels  ...  and  the  most  graceful  way  to  do  this  Is  a 
direct  approach  via  the  goto  or  Its  equivalent."  [K2,  p.  18]  Knuth  discusses 
eight  example  problems  and  points  out  the  virtues  of  several  solutions  that 
use  the  goto.  In  my  opinion,  not  one  of  these  solutions  Is  clearer  than  the 
solutions  without  the  goto  statements.  Consider,  for  example,  the  programs 
In  Figures  (6a)  and  (6b)  which  were  derived  from  the  "tree  searching"  examples 
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of  Knuth.  The  solution  using  the  goto  statenent  (6a)  Is  not  obviously  clearer 
than  the  D-structure  one  In  (6b).  Furthermore,  changing  the  name  of  the 
boolean  variable  "v"  to  a more  descriptive  one,  e.g.  "empty  space  found", 
makes  the  debate  almost  vacuous.  Clarity  Is,  of  course,  a highly  subjective 
quality,  but  I believe  that  a thoughtful  reading  of  these  examples  will 
support  my  contention. 

The  argument  from  efficiency,  that  the  goto  Is  less  time  consuming 
than  alternative  control  structures.  Is  frequently  made.  Knuth,  for  example, 
says  "Sooner  or  later  people  are  going  to  find  that  their  beautifully 
structured  programs  are  running  at  only  half  speed... [K2,  p.  3]  He  does 
present  several  example  programs  where  a solution  with  goto  statements  Is 
Indeed  more  efficient  than  solutions  with  alternative  control  structures 
(though  a factor  of  two  is  never  obtained).  Nevertheless,  It  Is  my  basic 
contention  that  all  such  example  programs  would  be  Just  as  efficient  If 
processed  by  a good  optimizing  compiler.  Certainly,  no  optimizing  compiler 
can  be  expected  to  perform  "macro-efficient"  optimizations  like  the  conver- 
sion of  a linear  search  Into  a binary  one.  On  the  other  hand,  redundant 
tests  and  repeated  actions  are  typical  of  the  "micro-efficient"  conditions 
that  can  be  eliminated  by  good  optimizing  compilers,  rare  though  they  may 
be.  This  latter  type  of  optimization  should  not  be  the  responsibility  of 
the  typical  programmer,  who  should  be  primarily  Interested  In  developing 
clear,  macro-efficient  programs. 

Similarly,  the  same  clarity  and  efficiency  arguments  do  not  support  to  any 
great  degree  the  multiple-exit  control  structures,  like  that  proposed  by 
Zahn  [Zl,  K2].  Furthermore,  these  structures  do  not  appear  to  provide  a 
more  "natural"  way  of  thinking  about  the  problem. 


.Si 


1 


-29- 


» My  third  conclusion  relates  to  the  utility  of  D '-structures  over 

D-structures.  Feeders  may  have  observed  the  use  of  case,  if-then,  and 
structures  (all  of  which  are  D-structures)  in  the  solution 

to  the  qualified  name  problem.  From  the  results  presented  earlier,  the 
only  real  differences  between  D and  D '-structures  is  notational  convenience. 
i For  example,  the  use  of  case  structures  can  often  prevent  the  need  for 

r 

multiple  nested  If-then-else  structures,  and  the  use  of  repea t-until 
structures  can  often  prevent  the  use  of  somewhat  artificial  while-do 
structures.  Since  D* -structures  preserve  the  Important  1-ln,  1-out  property 
of  D-structures,  the  notational  convenience  provided  by  D* -structures  is 
strongly  recommended. 

In  parting,  I must  admit  that  any  recommendation  for  a good  set  of 
control  structures  is  Indeed  subjective.  However,  I must  conclude  from  this 
examination  that  considerable  new  and  definitive  evidence  Is  needed  before 

r 

we  suggest  that  D or  D*  control  structures,  with  all  their  clarity  and  sim- 

- 

pliclty,  are  not  sufficient  for  the  practicing  programmer. 
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